2. Architecture Constraints
Ar42 specifications helper
Contents
Any requirement that constrains software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.
Motivation
Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. Constraints must always be dealt with; they may be negotiable, though.
Form
Simple tables of constraints with explanations. If needed you can subdivide them into technical constraints, organizational and political constraints and conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
2.1 Technical / Technological constraints
| ID | Constraint | Rationale / Source |
|---|---|---|
| T-1 | Local dev stack with laptops + Docker Desktop no corporate CI/CD or SSO in v1 Small ci/cd authorized to demonstrate and test containerization | Keeps scope manageable for a student project [D-0001] |
| T-2 | Vue 3 (+ Vite) SPA is the single front-end technology. No Angular or React components may be introduced. | Matches existing skills of 3/4 team members and Customer “preferred list”. [D-0002] |
| T-3 | Spring Boot 3 + Java 17 is the only back-end runtime; Gradle is not choosed (→ Maven). | Consistent with HEG course material and Customer ops stack. [D-0006] |
| T-4 | Primary RDBMS is MySQL 8 (Prod); in-memory H2 is required for local tests & CI. | Licensing, operations familiarity, fast feedback loops. [D-0003] |
| T-5 | “API First” – every service boundary must have an OpenAPI 3.1 contract. Mock servers & server stubs can be generated from it. | Enables parallel Front End Back End work, and will allow contract testing. [D-0007] |
| T-6 | Artefacts must run in a on Docker image that can be deployed on the any cloud provider. No cloud-specific PaaS features. | Matches free hosting offered by HEG sponsor [D-0008] |
| T-7 | All secrets (db pwd, JWT keys) must be injected via Docker secrets or env-vars – never committed. | Best practices and security guideline. |
| T-9 | All real-time user notifications must be delivered via **WebSocket over STOMP; HTTP polling is not permitted. | Zero-lag UX, reduced server load; agreed with front-end team |
2.2 Organisational / Process constraints
| ID | Constraint | Rationale / Source |
|---|---|---|
| O-1 | Development follows Scrum (2-week sprints) with a Kanban pre-sprint-0 and board. | Agreed project governance. [D-0004] |
| O-2 | Documentation must use the arc42 template, enriched with C4, BPMN and UML where helpful. | Aligns with latest documentation requirements trends and practice |
| O-3 | Deadline: all deliverables frozen by 23.05 May 2025 23:59 CET. No new features after that date. | Academic milestone. |
2.3 Standards & naming conventions
| ID | Constraint | Rationale / Source |
|---|---|---|
| C-1 | Language: code, comments & UI in English; academic docuemntation and user help in EN and/or FR. | Mixed Customer/HEG team – avoids confusion. |
| C-2 | Git workflow: trunk-based, short-lived feature branches; branch name feature/ID-short-title. | Keeps merge overhead low for a small team. |
| C-3 | Semantic Versioning 2.0 for artefacts; main = next unreleased minor. | Enables safe dependency management. |
Notes for reviewers
- The [D-000#] are document in the Annex E - Decision logs